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Abstract. This paper presents an extension to Hoare logic for pointer 
program verification. Logic formulas with user-defined recursive func- 
tions are used to specify properties on the program states before/after 
program executions. 

Three basic functions are introduced to represents memory access, record- 
field access and array-element access. Some ax;ioms are introduced to 
specify these basic functions in our logic. 

The concept Memory Scope Function (MSF) is introduced in our logic. 
Given a recursive function /, the MSF of / computes the set of memory 
units accessed during the evaluation of /. A set of rules are given to 
derive the definition of this MSF syntactically from the definition of /. 
As MSFs are also recursive functions, they also have their MSFs. An 
axiom is given to specify that an MSF contains its MSF. Based on this 
axiom, local reasoning is supported with predicate variables. 
Pre-state terms are used to specify the relations between pre-states and 
post-states. People can use pre-state terms in post-conditions to repre- 
sents the values on the pre-state. 

The axiom of assignment statements in Hoare's logic is modified to deal 
with pointers. The basic idea is that during the program execution, a 
recursive function is evaluated to the same value as long as no memory 
unit in its memory scope is modified. Another proof rule is added for 
memory allocation statements. 

We use a simple example to show that our logic can deal with pointer 
programs in this paper. In the appendix, the Shorre-Waite algorithm is 
proved using our logic. We also use the selection-sort program to show 
that our logic can be used to prove program with indirectly-specified 
components. 



1 Introduction 

Hoare's logic[T] can not deal with pointer programs because of pointer alias, i.e. 
many pointers may refer to the same location. A few extensions to Hoare logic 
have been made to deal with pointers or shared mutable data structures [2] [3] [1] • 



* This paper is supported 



Among them, separation logic is famous. That logic uses a memory model 
which consists of two parts: the stack and the heap. Pointers can only refer to 
data objects in the heap. The Hoare logic is extended with a set of proof rules 
for heap lookup, heap mutation and program variable assignment. Separation 
logic extends the predicate calculus with the separation-conjunction operator 
(*), which can separate the heap into different disjoint parts. To specify the sep- 
aration conjunction and related function symbols(i— > and -^), totally 14 axioms 
and proof rules are introduced. These axioms and rules are not strong enough 
to prove most programs. So five special classes of formulas arc defined based on 
the semantic of separation-conjunctions, i-> and 5 axioms and several seman- 
tic theorems are introduced to improve Separation Logic. Yet another two new 

[e] 

symbols (^, ©) and 11 axioms are introduced to deal with composite types 
(record-types and array- types) . Supplemental proof rules for assignment, alloca- 
tion/deallocation are also provided. Another disadvantage of Separation Logic, 
people still have to deal with low-level address manipulations, which has been 
generally avoided in high-level programming languages. A few small programs 
have been used to demonstrate the potential of local reasoning for scalability [B] . 
In that paper, the Shorre-Waite algorithm was proved using Separation Logic, 
on the assumption of many complicated logic formulas. 

This paper presents an extension to Hoare logic for verification of pointer 
programs. In order to deal with high-level program types abstractly and directly, 
we introduce three functions: * (memory unit access), Sz — ?• (record-field access), 
and &[] (array-element access). A set of axioms are used to model and specify 
the memory layout/access in pointer programs. 

The value stored in the memory unit referred by an address x is *a;. In 
this logic, the memory units for program variables and heap objects are treated 
uniformly. A program variable v corresponds to a constant memory address &lv. 
The value stored in v is expressed as As a consequence, program variables 
are no longer treated as logic variables in specifications. 

Recursive functions are used in program specifications. For a recursive func- 
tion defined using *, its value is relevant to a set of memory units. We show 
that this memory unit set can be expressed by another recursive function, called 
memory-scope function (MSF). The definition of the memory-scope function of 
/ can be constructed syntactically from the definition of /. 

The concept pre-statc terms arc introduced in this paper. They can help 
people specify the relations between pre-/post-states. 

This paper is organized as follows. We first introuce the syntax of programs 
and specifications in Section[2] In Section[3l we introduce the concepts of memory 
scopes and pre-state terms. A proof rule is introduced to specify how definitions 
of MSFs are constructed. Two axioms are introduced to specify the properties 
about memory scopes. To model memory access and layout in pointer programs, 
three functions and a set of axioms are introduced in Section [S] The axioms 
and proof rules for program statements are given in Section [6] Some other proof 
rules are given in Section [71 Section |8] describes how to write verifications in 



2-diniension form. The verification of the running example using our logic is 
presented in Section [HI Section [TUl concludes this paper. 

Appendix |X] presents the verification of an implementation of the Schorre- 
Waite algorithm. Appendix |B] presents an verification of a program template, 
i.e. a program with indirectly-specified components. 

2 Syntax of programs and specifications 

In this section, we give a brief description of the small program language used 
in this paper. 

2.1 The syntzLX of program expressions 

Besides the basic arithmetic and logical operators, three operators are intro- 
duced: *,&[],& — ^ n. The operator * is used to access the content stored in a 
memory unit; &[] is used to derive the address of an element of an array; & — n 
is used to derive the address of a field of a record. 

Formally, The syntax of program expressions is as follow. 

1. For a program variable v, &u is an expression. 

2. A constant (e.g. 1,2, true, false, nil) is an expression. 

3. Let 60,61,62 be expressions. 

(a) 6o?6i : 62 is also an expression; 

(b) 61-I-62, 61 — 62, 61*62, 61/62, not 61, 61 and 62, 61 or 62 are expressions; 

(c) *6i, &6i[62], &61 — ?► n are expressions. 

If we compare this small language with the programming language C, the op- 
erators & — ?> n (or &[]) can be viewed as a composition of & and — >■ n (or [] 
respectively). The semantic of eo?ei : 62 is same as the conditional expression in 
C. 

2.2 The type system of the program language 

The small program language used in this paper is strong-typed. In this paper, it 
is supposed that all programs under verification have passed static type check. 
Each expression e has a static type t, which means that at the runtime, cither e 
denotes a value of type < or e is undefined. 

The types used in programs include the basic types: int (for integers) and 
bool (for boolean values); pointer-types F{t), array-types ARR(i, e), and record- 
types REC((ni, ti) X ... X (nfc, tk)), where t,ti, . . . ,tk are types, ni, 712, ■ ■ ■ ,nk are 
k different names, c is a positive integer constant. We use Ptr as the super type of 
all pointer- types. People can also define user-types using the form name := type. 

If we view the new operators & — >■ and &[] as compositions of the C operator 
&, — !> and [], the type rules and well- formed conditions of program expressions 
are similar to that of the programming language C. However, it is required that 
* can only be applied to values of the set P(int), P(bool) and P(P(t)) for some 
t. 



Abbreviations Using the operators *,&[] and & — > n, we can fulfill any op- 
eration on arrays and records. However, an expression using & — > n and &[] 
directly may be difficult to write/read. For conciseness, we can use the following 
abbreviations in the programs such that we can write C-like expressions. (A new 
operator (&.) is introduced here.) 

— *(&e — ?> n), *(&e.n), and *(&ei[e2]) can be abbreviated as w, e — n, 
e.n, and ei[e2] respectively. 

— — ?► n, &(&ei — ni) -> 712, &(&ei.rii) — > n2 and &(&ei[e2]) — ?> n can be 
abbreviated as Szv.n, &(ei — > ni).n, &(ei.ni).n2 and &ei[e2].n respectively. 

— &(&?;[e2])[e3], &(&ei — > n)[e3], &(&:ei.n)[e3], and &(&ei[e2])[e3] can be ab- 
breviated as &(?;[e2])[e3], &(ei — >■ n)[e3], &(ei.n)[e3] and &(ei[e2])[e3] re- 
spectively. 

We can write concise expressions using these abbreviation rules. 

Example 1. Let a, i and j be three program variables. The type of i and j is int; 
The type of a is ARR(ARR(REC((/f , int) x (/2, bool)), f 00), f 00). We can 
write *{k{k{k{ka)[*{ki)])[*{ki)]) fl) to access the field fl of the clement 
in the ith row and the jth column. Using the abbreviation rules above, we can 
abbreviate this expression as a[i][j]./l. 

2.3 The syntax of program statements 

The syntax of program statements is as follows. 

st skip | * ei := 62 | * e := alloc(t) 

st; st I if (e) st else st \ while (e) st 

The type-rules and well-conditions of the statements are as follow. 

— For the assignment *ei :~ 62, *ei and 62 must have same static type. Further 
more, their type must integer, boolean, or a pointer type. 

— For the memory allocation statement := alloc(t), the static type of *e 
must be P{t). 

— For the while-statement and if-statement, the static type of e must be 
boolean. 

The operational semantic of these statements is similar to that of the program- 
ming language C. 

Example 2. The program depicted in Figure [1] is a running example used in this 
paper. The type of k and d is int. The type of root and p is P(Node), where 
Node = REC((;,P(Node)) x (r, P(Node)) x (if, int) x (D.uit)). This program 
first searches a binary search tree for a node of which the field K equals k. Then 
it sets the filed D of this node to d. 



pt:=root; 

while (pt— / k) 
{ 

if (k < pt — J< ) pt := pt ^ I else pt := pt — i> r; 

} 



Fig. 1. The program used as a running example 
2.4 Syntax of specifications 

In our logic, a specification is a Hoare- Triple of the form 

p {c} q 

where c is a code fragment, p and q are logic formulas with recursive functions. 
The formulas p and q are respectively called the pre-condition and post-condition 
of this specification. As we will use recursively-defined partial functions in pro- 
gram specifications, p and q should be formulas of some three- value logics that 
can deal with undefinedness. In this paper, we use the Logic for Partial Func- 
tions (LPF) [7] as the basic logic, i.e. p and q are LPF formula. However, other 
three-value logics can also be used. 

There also some other things should be noticed here. 

— Program variables and logic variables are different things in our logic. A 
program variable represents a memory block storing values. The values stored 
in a program variable may changed by code. A logic variable is a place-holder 
for a value. A logic variable appeared in pre-condition and post-condition 
represents the same value. 

— In our logic, the function * is used to represents the program state. So * has 
different interpretations in p and q. Consequently, the recursive functions 
in the specification defined based on * also have different interpretations 
accordingly. 

Formulas appeared in specifications are also strong-typed. Each logic variable 
has a static type, though we may omit it. The static types of terms in such 
formulas can be automatically decided. 

Example 3. Let isHBST, Dom, Map and FIdD be the recursive functions defined 
in Figure [2] Prog be the program depicted in Figure [TJ The specification 

Dutlying(p, {&p} U FldD(root)}) A isHBST(root) A k e Dom(root) 

{ Prog } ^ (1) 

p A isHBST(root) A Map(root) = Map(root)t{k ^ d} 

says that if the program starts it execution when root points to a binary search 
and k equals to the field K of some node in this tree, root still points to a binary 



search tree after the execution. The finite map represented by this tree is the 
same as the original map except that it maps k to d. 

^yiap(root) in the post-condition is a pre-state term. It means the map repre- 
sented by the BST on the pre-state. The definition and proof rules of pre-state 
terms will be presented later. 

Outlying(p, {&p} U FldD(root)}) is an abbreviation for p A {M{p) n ({&p} U 
FldD(root))} = 0). denotes the memory scope of the formula p. This spec- 

ification shows that the program modifies only the memory units in {&p} U 
FldD(root). If p holds on the pre-state, and is irrelevant to the memory units in 
this set, p still holds on the post-state. The concept of memory scopes will be 
explained in the next section. 



NodeSet(x : P(Node)) : SetOf(Ptr) 

= {x = nil)? : {{x} U NodeSet(x ^ /) U NodeSet(2: r)) 

Map(a: : P(Node)) : Map(int, int) 

= {x = nil)?0 : {x ^ K ^x^ D}tMap(a; /)tMap(a; r) 

MapP(2; : P(Node),j/ : P(Node)) : Map(int, int) 

= {x = nil)?0 : MapP(a: ^ Z)tMapP(x ^ r)] 

{{x = y)?0 : {x ^ K ^x~^ D}) 

Don (a; : P(Node)) : SetOf (integer) 

= {x = nil)?0 : {{x K] \J Dom(a; ->l)\J Dom{x r)) 

isHBST(2; : P(Node)) : boolean 

= {x = nil)?true : InHeap(a:) A isHBST(x ^ /) A isHBST(2: -i> r)A 
(Dom(x /) = 0?true : MAX(Dom(x I)) < x A')A 
(Dom(x -s> r) = 0?true : x ^ K < MIN(Dom(a; r))) 

FldD(x- : P(Node)) : SetOf(Ptr) 

= {x = nil)?0 : D} U F\AD{x I) U F\dD{x r)) 

Fig. 2. The definitions of a set of recursive functions 



3 Memory scopes and pre-state terms 
3.1 Terms denoting pre-state values 

In many cases, people are interested in the relationship between the values be- 
fore/after program executions. Merely specifying the property of the program 
state after program execution is not sufficient for this purpose. In our logic, we 
use pre-state terms to denoting values on pre-states in post-conditions. 



Definition 1. Pre-state terms Let e be a term containing no pre-state sub- 
term, ^ is a pre-state term. 

Pre-state terms can appear in both pre-conditions and post-conditions. A pre- 
state term %" denoting tlic value of e interpreted based on tlie pre-state before 
execution. In pre-conditions, % and e is interchangeable. We have the following 
two proof rules. 

p[e/x] {s} q ,pp;p,s {s} q ,ppp „^ 

pi'eM {s} q p[eM {s} q 

In the rest of this paper, we will inter-change e and V in pre-conditions with- 
out mentions these proof rules. For convenience, for a formula Q (or a term e) 
containing pre-state terms, we use Q (or e respectively) to denote the formula 
(or term) derived by replacing all pre-state terms in Q (or e) with their original 
forms. For example, Ipt ~ t is >i=pt = t. 



3.2 Memory scopes 

Memory scope form of terms An execution of a piece of code may change 
the values stored in some memory units. The function symbol * has different 
interpretations in the pre-condition and post-condition of a specification. So 
does the functions defined based on As a consequence, a term may denote 
different values in the pre-condition and the post-condition. However, the value 
of a term e relies only on a finite set of memory units. This set can also be 
expressed as a term, called the memory scope form of e, denoted as 971(e). Given 
a term e, 9}T(e) is defined as follow. 

— For any pre-state term V, S[Jl(%) is 0. 

— If e is a logical variable or a constant, 971(e) is 0. 

- If e is of the form /(ei, . . . , e„), 971(e) is 97T(ei)U. . .U97l(e„)U97t(/)(ei, . . . , e„), 
where 97t(/) is the memory scope function of /. 

- If e is of the form eo?ei : 63, 971(e) is 97l(eo) U (eo?97T(ei) : 97l(e2)). 

Though is evaluated on the pre-state, its value is not modified by the execu- 
tion. So, 97l(V) is 0. 



Memory scope functions Intuitively speaking, 97l(/)(xi, . . . , e^) computes 
the set of memory units accessed during the evaluation of /(xi, . . . ,a;„). The 
argument types of 971(/) is the same as those of /. The result type of 97l(/) is 
SetOf(Ptr). Given a function /, the definition of 97l(/) can be derived as follow. 

— 97t(/)(a:i, . . . , a;„) = if / is a function symbol associated with basic types 
or abstract types (for example, +, —, x ,/,>,<, G, C . . .), or & — > n, &[], kv 
for some program variable, nil. 

— 97t(*)(a;) = {x}. That is, *x access the memory unit referred by {x}. 

— If / is (recursively) defined as /(xi, . . . , a;„) = e, we have the definition 
97t(/)(xi,...,x„)^97t(e). 



In LPF, a function definition is also a formula. We have the following proof rule. 

fi^i^---^^n)=e (SCOPE-FUNC) 

an(/)(.Ti,...,x„) = 971(e) 

Example 4. Let e be a[i\[j].fl (i.e. *(&(&(&(&a)[*(&i)])[*(&j)]) ^ /I)), 9Jt(e) 
is {&i,&i,&(a[*][i]./l)}. 

The memory scope form of (x = nil)?0 : ({x-}UNodeSet(a; /)UNodeSet(a- 
r)) is equivalent to {x = nil)?0 : {kx ^ 1} U 97l(NodeSet)(.T ^ /) U {kx 
r} U SEJl(NodeSet)(a- — r). According to the definition of NodeSet in Figure [2J 

art(NodeSet)(a;) = (x = nil)?0 : {kx I, kx r}U 
»l(NodeSet)(a- -^l)LI 9Jt( NodeSet) (x ^ r) 

The definition of 3Jl(NodeSet) is equivalent to that of MSFjr depticted in Figure[3] 
The following tabic lists the memory scope functions for the functions defined 
in Figure [5] and Figure [31 



Recursive functions 


Memory Scope Functions 


NodeSet, MSF,^, MSF(,rfc, MSF,^^, FIdD 


MSF,,. 


Dom, isHBST 


MSF(^A; 


Map 


MSF,,.M 


MapP 


MPP,„ 



□ 



MSFi^(2: : P(Node)) : SetOf(Ptr) 

= {x = nil)? : {{kx ^l,kx-^r}U MSFi,.(x ^ /) U MSF,r(x -> r)) 

MSF;^fe(x : P(Node)) : SetOf(Ptr) 

^{x = nil)?0 : {{kx K, kx -^l,kx^r}U MSF,,fe(x I) U MSfirk{x r)) 

MSFirkd{x : P(Node)) : SetOf(Ptr) 

= {x = nil)?0 : {kx K, kx D,kx ^ I, kx ^ r} U MSFirkd{x I) U MSFirkdi 

MPPm{x : P(Node),2/ : P(Node)) : SetOf(Ptr) 

= {x^ nil)?0 : {kx -^l,kx-^r}U MPP„(x ^ /) U MPP„,(2,- ^ r)U 
{{x = j/)?0 : {kx K, kx ^ D}) 



Fig. 3. The scope functions 



Memory Scope for Formulae Roughly speaking, the memory scope term 
of a formula is the union of the memory scopes of the terms of this formula. 



To formally define the memory scope of a formula p, it is required that each 
quantified variable in p has a unique name, and is different from the free variables 
in p. Please be noticed that for an arbitrary formula p, we can easily get an 
equivalent formula satisfying this condition by variable renaming. The memory 
scope term of a formula p is defined as follow. 

1. If p is a boolean- typed term e, dJl{p) is 971(e). 

2. If p is ei ~ 62 or ei —— 62, 93t(p) is 3Jl(ei) U 93T(e2). The symbol == is 
the strong equivalence in LPF. It means that either both side of == are 
undefined, or they equal to each other. 

3. li p is pi A p2,M{p) is m{pi)um{p2). 

4. If p is V, ^(p) is an(p') 

5. lip is \/x-p',m{p) is m{p'). 

An axiom about memory scopes If all the functions in a term e are either 
basic functions or recursively defined functions, we can find that the evaluation 
of S[Jl(e) tracks the evaluation process of e, and records all the memory units 
accessed during this process. All the memory units accessed during the evaluation 
of dJt{e) are also accessed during the evaluation of e. We have the following two 
axioms about memory scope functions. 

m{p)i ^ m{m{p)) c m{p) (scope-i) 

m{e)i ^ m{m{e)) C m{e) (SCOPE-2) 

Here, I is an operator in LPF. 9JT(e) I and 9?T(p) i respectively mean that 9Jl(e) 
and 9K(p) are denoting. 

4 Supporting local reasoning 

In our logic, local reasoning is supported using predicate variables. Usually, a 
specification is of the form 

p A {M{p) n e = 9) A pre {s} p A post 

We can substitute p with other formulas to get new assertions about s. The 
static type of the term e is SetOf(Ptr). It is an over-approximation of the set of 
memory units modified by the code s. The premise (9Jl(/5) fl e = 0) means that 
p is irrelevant to the values stored in the memory units in e. Thus, p still holds 
when s halts normally. 

For conciseness, in the rest of this paper, we use Outlying(/9, e) as an abbre- 
viation for p A (9K(/o) n e = 0). The assertion above can be written as 



Dutlying(p, e) A pre {s} p A post 



Example 5. Considering the program depicted in Figure[TJ The program changes 
only the memory unit &p and the field D of some node of the tree. The specifi- 
cation [T] shows that for any predicate p which is irrelevant to the memory unit 
&:p and the field D of any nodes in the tree, if p holds on the pre-state, it still 
holds on the post-state. 

Theorem 1. Let p be an arbitrary predicate symbol. Let r be a predicate. As 
mentioned previously, r is derived by replacing each pre-state term "fe" with e. 

Dutlying(p, e) ^p { s } p ^q p Ar ^ {M{r) n e = 0) 
p Ar { s } q Ar 

Proof. Substitute p with r and expand Outlying in the first premise, we have 

r A {M{r) f] e = 9) A p { s } r A q 
Apply the proof rule PRE-2, we have 

r A (SH(r) ne = 0)Ap{.s}rAg 
From the second premise and the consequence rule (presented later), we have 

rAp{s}rAq 

□ 

Theorem [1] will be used frequently to derive global assertions based on the local 
assertion of a statement. We call an application of this theorem as an expanding. 

5 The axioms about memory access and layout 

In this section, we present some axioms about memory access and memory lay- 
outs of composite types. In the implementation of real program languages, mem- 
ory layouts for composite types are compiler-dependent. So computing the ad- 
dress of a component in a composite-typed data by address-offsetting is not a 
good choice. In our logic, we use a set of axioms to specify such memory layouts 
abstractly. 

5.1 The auxiliary function Block 

We define an auxiliary function Block : Ptr — > setof(Ptr) to denote the set of 
memory units in a memory block. The definition of Block is as follows. 
Block(r) = if 7' = nil. Otherwise Block(r) = 

{r} if *r is of type int, bool or Ptr 

U„ field name of t Block(&r -> Ti) If T ! P(t) aud i is a record type 
U -lo Block(&r[i]) if r : P(ARR(i', c)) for some t' 

Intuitively speaking, Block(r) is the set of memory units in the memory block 
referred by r. 



5.2 The axioms 



There is no memory-deallocation statement in our small program language. Each 
time a memory block is allocated, the memory units of pointer types in this block 
are initialized to nil. Thus, a non-nil pointer always refers to a valid memory 
unit or memory block. We have the following axiom. 

X : V{t) ^xi^xli\^*x■.t (MEM-ACC) 

According to the type rule of t can only be int, bool, or pointer types. The 
predicate e : t means that the term e denotes a value of the type t. 

Two different memory blocks are either disjoint, or one of them contains 
another one. We have the following axiom. 

Block(a;) n Block(y) = 0V (mvm RT V\ 

^ ^ ^ Block(a;) C Block(y) V Block(y) C Block(x) lMii.M-Ui.Kj 

Here, the static type of x and y must be pointer types. 

A unique memory block is assigned to each declared program variable. Fur- 
thermore, such a memory block is not contained by any other memory blocks. 
So we have the following axioms. 

hv ^ nil (PVAR-1) 
kvi ^ kv2 (PVAR-2) 
Block(&i;) Block(x) (PVAR-3) 

Here tj is a program variable, vi and V2 are two different program variables. The 
static type of a; is a pointer type. 

A memory block for a record-typed data is allocated as a whole. That is, 
when a record-typed memory block is allocated, the blocks for all its fields are 
allocated. We have the following axiom. 

x^nil=>kx^n^ nil (REC-1) 

Here, the static type of x is P(REC(. . . x (n, t) x . . .)) 

In a record-typed memory block, the memory blocks for different fields are 
disjoint with each other. If the static type of x is P(REC(. . . x (ni,ii) x . . . x 
(712, ^2) X • ■ ■)), we have the following axiom. 

X 7^ nil ^ Block(&a; rii) n Block(&x ^ 712) = (REC-2) 

Similarly, we have the following two axioms. Here, the static type of x is 
P(ARR(t, c)). The static type of y, 2/1,1/2 is int. The axiom ARR-1 says that 
an array-typed memory block is allocated as a whole, i.e. when an array-typed 
memory block is allocated, all of the memory blocks for its elements are allocated. 
The axiom ARR-2 says that the memory blocks allocated for different elements 
are disjoint with each other. 

{x ^ nil) A (0 < ?/ < c) ^ kx[y] / nil (ARR-1) 



{x ^ nil) A (0 < yi < c) A (0 < 2/2 < c) A (yi 7^ ^2) 

Block(&a;[yi]) n Block(&x[y2]) = 



6 Axioms and proof rules of program statements 



In this section, we present the axioms and proof rules to specify the effect of 
program statements. There are three axioms for primitive statements and three 
proof rules for control flow statements. 

6.1 The axiom for skip 

The skip statement changes nothing. If a formula q hold before the execution of 
skip, q still holds after the execution. This is specified by the following axiom. 

q { skip } q (SKIP-ST) 

6.2 The axiom for assignment 

For an assignment *ei := 62, it is required that ei evaluates to a non-nil pointer, 
i.e. it refers to a memory unit, and 62 evaluates to a value on the pre-state. One 
the post-state, the memory unit stores the value of 62 evaluated on the pre-state. 
Furthermore, if ei is not in the memory scope of a formula p, p still holds after 
the execution. This is specified by the following axiom. 

Outlying(p, {ei}) A (ei ^ nil) A (e2 i) 

{*ei 62} (ASSIGN-ST) 

p ^ = ^) 

Here, J, is an operator in LPF: 62 \r means that 62 is evaluated to some value. 

Example 6. Considering the assignment pt := pt — > Z in the program depicted 
in Figure [TJ As &pt ^ nil and (pt ^ nil) (&pt -> I / nil) ^ (pt -> I) J,, we 
can have the following assertion. 

Outlying(p, {&pt}) A (pt ^ nil) {pt := ^ 1} p A {*tz^t = pt I) 

Because 9Jt(&pt) n {&pt} = 0, substitute p with p A (i^pt = &pt), and apply 
the consequence rule (presented later), we have 

Dutlying(p, {&pt}) A (pt 7^ nil) {pt := pt ^ I] p A (pt = 'pt ^ I) 

6.3 The axiom for memory allocation 

For an allocation statement *ei := 62, it is required that ei evaluates to a non-nil 
pointer. After the execution, the value stored in the memory unit referred by 
refers to a memory block that is unreachable on the pre-state. This allocation 
statement modifies only the memory unit referred by ei and the memory unit 
newly allocated. If a predicate p holds on the pre-state and ei is not in the 



memory scope of p, p still holds on the post-state. This is specified by the 
following axiom. 

Dutlying(p, {ei}) A (ei ^ nil) 

{*ei := alloc(t)} (ALLOC-ST) 
Outlying(/9, Block(*^)) A ^ nil) A Init(*^) 

The predicate Init(a;) is defined as Vy e Block(a;) • y : P(P(t)) = nil. It 

means that all the pointers stored in the block referred by x is initialized to nil. 

Example 7. Considering the sequential statements t := alloc(Node); t ^ k := 
k; t — !> d := d. From the axiom ALLOC-ST, we have 

Outlying(p, {&t}) 

{t := alloc(Node); t ^ fc := k; t ^ d := d} 
Outlying(p, Block(t)) A (t 7^ nil) A (t ^ / = nil) A (t r = nil)A 

(t ^ fc = k) A (t ^ = d) 



6.4 The proof rule for if-statement 

The proof rule for if-statcment is almost same as the one in Hoarc's logic. The 
only difference is that the conditional expression should always evaluate to a 
boolean value. 

{pAe){si}q {p^^e?){s2}q (IF-ST) 



p A (e V -le) { if (e) si else S2 } 9 



6.5 The proof rule for while-statement 

The proof rule in our logic is essentially same as the corresponding one in Hoare's 
logic. The only difference is that we require that the invariant implies the de- 
finedness of the conditional expression. We have the following rule. 

(WHILE-ST) 



p A (e V ^e) { while (e) s }-ie f\p 
where p is a formula containing no pre-state term. 



6.6 The proof rule for sequential statements 

The two statements in a sequential composition Si;s2 execute sequentially. If 
we prove the assertions about si and S2 respectively, we can compose these two 
assertions into an assertion about Si;s2. As the pre-state of si is different from 
that of S2, pre-state terms in two assertions should be eliminated. 



P^^^^'^ (SEQ-ST) 



p{si]S2}r 

where p, q and r contain no pre-state term. 



Example 8. In the proof rules for while-statements and sequential statements, 
the pre-/post-conditions contain no pre-state terms. To prove the relation be- 
tween pre-state and post-state, we can first prove an assertion with free logical 
variables, and then put pre-state terms into it using the proof rule SUBSTITU- 
TION, which will be presented in Section [T] 

Let X, y, z be three integer program variables. Vx,Vy,Vz be three logic vari- 
ables. We have the following two assertions. 

Outlying(pi, {&x}) {x := x + 1; } pi A x = V + 1 
0utlying(p2, {&y}) {y := y - z; } A y = ^ - z 

Substitute pi and p2 with Dutlying(p, {&x, &y}) A {vx = ^) A {vy ~ y) and 
Outlying(p, {&;x, &y}) A (x = -|- 1) A {vy = "y) respectively, then apply the 
consequence rule (presented later), we have 

Outlying(/9, {&x, &y}) A {v^ = x) A {vy = y) 

{x:=x+l;} 
Dutlying(/9, {&x, &y}) A {vy = y) A (x = + 1) 

Dutlying(p, {&x, &y}) A (x = + 1) A {vy = y) 

{y :=y-z;} 

Dutlying(/9, {&x, &y}) A (x = + 1) A (y = Vy - z) 

Apply the proof rule for sequential statements, we have 

Outlying(/j, {&x, &y}) A {v^ x) A {vy = y) 

{x:=x+l; y:=y-z;} 
Outlying(/9, {&x, &y}) A (x = + 1) A (y = Vy - z) 

Applying the rule SUBSTITUTION, substitute Vx and Vy with V and V re- 
spectively, we have 

Outlying(p, {&x, &y}) 

{x:=x+l; y:=y-z;} 
Outlying(p, {&x, &y}) A (x = ^ + 1) A (y = ^ - z) 

Substitute p with Outlying(po, {&x, &y}) A (w^ = z * V -|- V)i and applying the 
consequence rule, we have 

Outlying(po, {&x, &y}) A (w,^ = z * x + y) 

{x:=x + l; y:=y-z;} 
Outlying(po, {&x, &y}) A = z * x + y) 

Apply the proof rule for while-statements, we have 

Outlying(po, {&x, &y}) A = z * x + y) 

{while (y > z) begin x := x + 1; y := y — z; end } 
Outlying(po, {&x, &y}) A (w^ = z * x + y) A (y < z) 



From the proof rule SUBSTITUTION, we have 

Outlyiiig(po, {&x, &y}) A (V = z * x + y) 

{while (y > z) begin x := x + 1; y := y — z; end } 
Outlying(po, {&x, &y}) A = z * x + y) A (y < z) 



7 Other proof rules 

In this section, wc presents the rest of the proof rules in our logic. Most of them 
are adopted directly from Hoarc's Logic. The consequence rule says that provided 
an assertion, we can strengthen the pre-condition, or weaken the post-condition. 

p{s}q p'^p q^q^ (CONSEQ) 



p' {s} q' 

The proof rules CONJUNCTION and DISJUNCTION is same as the ones in 
Hoare's logic. 

P^'^'' P'^'^"' (CONJUNCTION) 



p Ap' {s} q A q' 
p{s}q p'{s}q' 



(DISJUNCTION) 



p' {s} g V q' 

The proof rules ALL and EXIST are respectively the generalized version of 
CONJUNCTION and DISJUNCTION. 

p{s}q 



Vx • p {s}\/x ■ q 
p{s}q 



where x is arbitrary (ALL) 
where x is arbitrary (EXIST) 



3x ■ p {s}3x ■ q 

The proof rule SUBSTITUTION says that we can substitute a variable with 
a term e and its pre-state form respectively in the pre-condition and the post- 
condition, as long as e is denoting in the pre-state. 

p{s}q p^el 



p[e/x] {s}q[ir/x 



where x is arbitrary (SUBSTITUTION) 



8 Concise form of proofs 

For conciseness, we write code in the following manner. 
— For a sequential composition of si; S2, we write 

{P} 

Sl 

U} 

S2 

{r} 



to show that we can first prove p{si}q and ^{52}^, then derive the assertion 
^{•Sij 52}*" by the sequential statement rule. It is required that p, q, r contain 
no pre-state term. 

— For a if-statement if (e) si else S2, we write 

{p^ (eV-.e)} 
if (e) 
{p^e} 

Si 

U} 

else 

{p A -le} 

U} 

to show that we can first prove p A e {si} q and p A -le {s2}q, then derive 
p A (e V -le) {if (e) si else S2} q by the proof rule for if-statements. 

— For a while-statement while (e) do s, we write 

{p A (e V -.e)} 
Vifhile (e) 

{pAe} 

s 

{pA (eV-.e)} 
{p A -le} 

to show that we can first prove that p is the invariant of this while-statement, 
then get the assertion p A (e V -le) {while (e) do s} p A -le. 

— An application of the consequence rule 

p{s}q p'^p q^q' 
p'{s}q' 

is written as 

{P'} 

s 

{<?} 

— An substitution of predicate variables or an application of Theorem ?? 



{p'} {P A r} 

X ^ e 'f p r 

{p} {Outlying(p, e) A p} 

s s 

Ix ^ i p r 

{?'} {gAr} 



Please be noticed that according to the proof rule SUBSTITUTION, if we 
substitute x with e, q' is derived by substitute x'mq with %. When substitute 
p with r, we must prove the second premise, i.e. p Ar ^ (9Jl(r) n e = 0). 

9 The proof of the running example in the concise form 

Let MSet be 

{&pt} U FldD(root) 

Let INV be the formula 

Outlying(po,^^'S'et) A isHBST(root) A Map(root) = .tA 
(pt 7^ nil) A (pt e NodeSet(root)) A (k e Dom(pt)) 

The proof of the specification [T] in the concise form is depicted in Figure SI 
The following are the properties about the recursive functions used in this proof. 

isHBST(a;) ^ &pt ^ MSF,^(x) U MSFirk{x) U MSFirkd{x) 

isHBST(a;) A pt G NodeSet(x) ^ 

kpt-)- D MSF(^fe(a;) U MSF;r(a;) U MPP„(x, pt) 

isHBST(.T) A{y e Dom(a:)) A {y < x ^ K) ^ y e Dom(a; I) 

isHBST(x) A (y e Dom(a;)) A{y>x^K)^ye Dom(a- r) 

isHBST(a;) A (y 6 NodeSet(a;)) ^ 

Map(a;) = MapP(a::, y)t{y K ^ y ^ D) 

NodeSet(a;) : SetOf(Ptr) =^ a; £ NodeSet(a;) 



10 Conclusions and further works 

In this paper, we present an extension of Hoarc logic to deal with pointer pro- 
grams. The pre-conditions and post-conditions are logic formulas with recursive 
functions. 

Three functions (*,&—> n and & []) are respectively used to represents mem- 
ory unit access, record-field access, and array-element access. These functions are 
specified by a set of axiom. These axioms formally specify our memory models 
with the following properties. 

— A non-nil pointer always refers to a valid memory unit or memory block. 

— Two different memory blocks arc cither disjoint, or one of them contains 
another one. 

— Each declared program variable is assigned an unique memory block. 



{Outlying(po, A^Set) A isHBST(root)A 

Map(root) = ^ap(root) A k e Dom(root)} 
X Map(root) 
{Outlying(po, A/S'et) A isHBST(root)A 

Map(root) — x Ak £ Dom(root)} 
pt := root; 
{INV} 

while {pt^K / k) 
begin 

{INV A (pt^A' / k)} 
if (k < pt ^ A' ) 

{INV A (pt->A / k) A (k < pt ^ A')} 
^ {Outlying(po, A'/Set) A isHBST(root) A Map(root) = xA 

(pt -)• Z / nil) A (pt ^ Z G NodeSet(root)) A (k G Dom(pt I))} 
pt := pt — !> / 

{Outlying(/9o, MSet) A isHBST(root) A Map(root) = xA 
(pt / nil) A (pt e NodeSet(root)) A (k e Dom(pt))} 
^ {INV} 
else 

{INV A (pt^A / k) A ^(k < pt ^ A')} 
^ {Outlying(po, A/Set) A isHBST(root) A Map(root) = xA 

(pt ^ r / nil) A (pt r G NodeSet(root)) A (k G Dom(pt r))} 
pt :— pt — S> r; 

{Outlying(po, A/Set) A isHBST(root) A Map(root) = xA 
(pt / nil) A (pt G NodeSet(root)) A (k G Dom(pt))} 
^ {INV} 
{INV} 
end 

{INVA^(pt->A'/ k)} 
=» {Outlying(po, AfSet) A isHBST(root)A 

MapP(root, pt)t{pt -> A' i-^ d} = x-t{k M> d}A 

(pt / nil) A (pt G NodeSet(root)) A (k G Dom(pt))} 

t pi ^ Outlying(po, MSet) A isHBST(root) A . . . A (k G Dom(pt)) 
{Qutlying(pi, &pt ^ D) A pt / nil} 
pt D — d; 
{pi A pt ^ D = d} 

i pi Qutlying(po, MSet) A isHBST(root) A . . . A (k G Dom(pt)) 
{Outlying(po, A/Sef) A isHBST(root)A 
MapP(root, pt)t{pt -i> A i-> pt -s- D} = x-t{k i-^ d}A 
(pt / nil) A (pt G NodeSet(root)) A (k G Dom(pt))} 
=» {po A isHBST(root) A Map(root) = x{{k h-)- d}} 
J, x ^ ^ap(root) 
{po A isHBST(root) A Map(root) = ^ap(root)t{k i-^ d}} 



Fig. 4. The proof in code of the running example 



— A memory block with a composite type is always allocated as a whole. The 
memory blocks allocated for different components of a composite type are 
disjoint with each other. 

To support local reasoning, we use specifications of the form 

p A {M{p) ne^9) Apre { s } p A post 

In this specification, e represents an upper bound of the memory set modified by 
s. We can substitute p with proper predicates in this specification to get global 
specifications. 

We use pre-state terms to denoting values before program executions. Pre- 
state terms can appear in both pre-conditions and post-conditions. A pre-state 
term ^ denoting the value of e interpreted based on the pre-state. In pre- 
conditions, % and e is interchangeable. The difference between V and e is that 
the memory scope form of is 0. 

On a specific program state, the value of a term e relies only on a finite set 
of memory units. This value of e docs not change if the contents stored in these 
memory units keep unmodified. We show that such a memory unit set can be 
expressed using a term constructed syntactically. Given a user-defined recursive 
function, we can construct another recursive function to represents the set of 
memory units accessed by this function during its evaluation process. We use an 
axiom to specify the properties about memory scope terms and memory scope 
functions. 

For the program statements, we present an axiom for assignment statements, 
and an axiom for memory allocation statements. Other axioms and proof rules 
are same as the ones in Hoare's logic. 

This logic has the following advantages. 

— The axioms and proof rules in our logic is simpler comparing to those of 
Separation Logic. In Separation Logic, to deal with the separation conjunc- 
tion, 14 axioms are introduced for general cases. Besides these, five special 
classes of formulas are defined based on the semantics of the separation con- 
junction. More axioms and theorems are given for these special formulas. To 
apply these special axioms and rules, people have to judge wether the formula 
is really in the class based on the semantics of separation conjunction. 

— This logic deals with high-level program types (record/array) directly. Sep- 

[e] 

aration logic introduces two new logical symbols (m>, Q) and 11 axioms to 
deal with records and arrays. People still have to deal with composite types 
with low-level address manipulation. 

— This logic is easy to learn. Most of the knowledge (for example, recursive 
functions, FOL, memory layout of composite P- types.) in this logic have 
been (explicitly or implicitly) taught in undergraduate CS courses. For ex- 
amples, the concept of recursive functions and first order logic are already 
taught in undergraduate CS courses. The proof rules about program vari- 
ables, *, & — > n, &[] are taught informally in the undergraduate courses 
about programming languages and compilers. 



— This logic supports reuse of proofs. Most of recursive functions and their 
proved properties are about data structures. They are independent of the 
code under verification. So these properties can be reused in verification of 
other code using same data structures. It is possible to build a library of pre- 
defined recursive functions, their memory-scope functions, and their verified 
properties. 

— People can easily specify and verify relations between pre-/post-states with 
pre-state terms introduced in our logic. 

— Our logic supports local reasoning precisely. The upper-bound of memory 
units modified by the program can be specified by a term. 

We also use several examples to show the efficacy of our logic. The example 
in the Appendix [B] shows that our logic can also deal with program templates, 
i.e. a program with some components indirectly specified. 

In the future, we will extend our logic to deal with more programming lan- 
guage concepts: function calls, function pointers, class/object, generics, and so 
on. At the mean time, we will try to build a library of pre-defined recursive 
functions, their memory scopes, and their properties for frequently used data 
structures. 
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A Another example: the Schorre-Waite algorithm 
A.l The Program 

Types and Variables The Schorre-Waite program to be verified, together with 
a type definition and three variable declarations, is depicted in Figure [5] In the 
program, we use some abbreviations for conciseness. 



CONDITION^ft 


(p ^ nil ? true : ((t = nil) ? false : -it — > mk) 


CONDITIONi 


(t = nil ? true : t — mk) 


CONDITION2 


(p — !> chk) 



The program is an elaborative implementation of the depth first search algo- 
rithm. The search path is stored in a linked list, of which the links reuses the 
memory cells for the field I or r. 



Type T: Rec(l : P(T), r : P(T),chk : boolean, mk : boolean)) 

Three variables; root,t, p declared with type P(T). 

(1) t — root; 

(2) p-nil; 

(3) while (CONDITIONuih) do //stack not empty or t not explored; 

(4) begin 



(5) if (CONDITIONi)//t is already explored or t is nil; 

(6) then 

(7) if (CONDITION2) then //POP; 

(8) begin q t; t := p; p := p — S> r; t — >• r q; end 

(9) else //TRY right neighbor; 

(10) begin 

(11) q— t; t := p ^ r; p ^ r — p I; 

(12) p — S> I q; p ^> chk :— true; 

(13) end 

(14) else //t is not explored. PUSH t into the stack; 

(15) begin 

(16) q:=p; p — t; t — t -> I; p ^ I := q; 

(17) p mk := true; p — > chk := false; 

(18) end 



(19) end 



Fig. 5. The Schorr- Waite Algorithm 



A. 2 Recursive functions 



We use two constants Lq and Roto represent the edges. They are two maps. For 
a node x in the graph, Lo(a;) and Ro(a;) are respectively the left-neighbor and 



right-neighbor of x in the initial graph. The constants tq is the starting node. 
The constant NSq represents the smahest set satisfying the following properties. 

- ro e NSo; 

- x G NSo A Lo(a;) ^ nil Lo{x) E NSq; 

- cc G NSo A ^o{x) ^ nil => Ro{x) G NSq. 

The definitions of the recursive functions used in the specification and the 
proof arc depicted in Figure IHl The function Stack(x) retrieves the segment of 
the current path starting from x. The boolean-typed function isAcyclic(x) as- 
serts that the list x is acyclic. The boolean-typed function Path Prop asserts the 
properties about the current path. 

The memory scope over-approximations for some functions are as follow. 



Recursive Functions 


Memory scope over-approximations 


NextNode(a;) 


{x = nil)?0 : kx chk 


Explored (a;) 


(x = nil)?0 : {kx mk} 


Stack(a;) 


{Block(a;) a- G rng(Stack(a:))} 


isAcyclic(s) 






Let Marked Fid Mk be {ky mk\y G NSo A y ^ mk}. As 

Explored(a;) A x- G NSq => kx ^ mk G MarkedFldMk 

we have the following properties. 

lnPath(a:) A rng(Stack(2;)) C NSo =^ 

S[H(lnPath)(.T) C {Block(2/)|y G rng(Stack(2;))} U MarkedFldMk 

OutPath(.s) A s C NSo ^ 

an(OutPath)(s) C {Block(2;)|x G s} U MarkedFldMk 

A. 3 The specification 

Let MSet be {&p,&t,&q} U {Block(a;)|2; G NSo}. Notice that m{Set) is 0. The 
program can be specified as follow. 

Outlying(po, A^Set) A root = ro 

A:reNSo(("^ ^ "^^^ ^ ("^ ^ ^^^^ A (a; ^ I = Lo(a;)) A (x ^ r = Ro(a;))) 
{the program} 

P ^ f\xetlSoi^ mk A X chk A (x I = Lo(x) A (x ^ r = Ro(x)) 
A. 4 The proof 

The main part of the program under verification is a while-statement. The in- 
variant of this while-statement is as follow. 

Outlying(po,M5'ei) A Acyclic(Stack(p)) A OutPath(NSo - rng(Stack(p)))A 
InPath(p) A (NextNode(p) t) 



NextNode(2; : P(T)) : P(r)) = (a; = nil)?ro : {x chk?Ro(a;) : Lo{x)) 
Explored (x : P{T)) : boolean = [x = nil)?true : a; — J- mk 
Stack(a; : P(r)) : SeqOf(P(T)) ^ 

{x = nil)?[] : a::'~~Stack(a; — >■ chk7x — >■ r : x — >■ I) 

isAcyclic(s : SeqOf(P(r))) : boolean = 

s = []?true : head(s) ^ rng(tail(s)) A isAcyclic(tail(s)) 

In Path (x- : P(r)) : boolean = x = nil?true : 

X G NSo A X — ^ mk — trueA 

/ X chk?((NextNode(x r) = x) A (x ^ I = Lo(x)) A Explored(Lo(x)) : 



\^ ((NextNode(x I) = x) A (x -> r = Ro(x)) 

lnPath(x chk?x — s> r : x ^ I) 

OutPath(x : SetOf(P(r)) : boolean = 

. / X ^ \ = Lo(x) A X — ^ r = Ro(x)A 

/\yex y(x ^ mk?(x chk A Explored(Lo(x)) A Explored(Ro(x))) : true) 



In the rest of this paper, we use SW_INV to denote this formula. The framework 
of our proof is depicted in Figure [71 In the rest part of this section, we will prove 
the assertions about the sequential statements in line (7), (9) and (11). 



A. 5 The assertions about the assignment sequences 



The assignments in Hne (8). Let EXPANDi be the following formula. 

Outlying(po, MSet) A Acyclic(Stack(^^=rr)) A lnPath(^^=rr)A 
(NextNode(^^=rr) = V) A OutPath(NSo - {V} - rng(Stack(^^=rr)))A 
Explored(Y) A Explored(Lo(^)) A Y = Ro(V) A ^ mk 

Form the definition of memory scope terms, and the properties about over- 
approximation of 9Jl(lnPath) and 93t(OutPath), 



EXPANDi ^ (S!Jl(EXPANDi) n MSet) C 

{Block(x-)|a; e NSq - {p}} U MarkedFldMk U {&p -> mk}U 
(t = nil?0 : {&t ^ chk}) U (Lo(p) = nil?0 : {&Lo(p) ^ chk}) 




Fig. 6. The recursive functions used in the proof 



{Outlying(po, MSet) A (root = ro)A 
Aa:eNSo((^^ ^ '^'^) ^ ^ ^^'*^) A (a ^ I = Lo(s)) A (a: ^ r = R()(a::)))} 

(1) t — root; 

(2) p-nil; 

{Outlying(po, MSet} A t = root A p = nil} 
^ {SWJNV} 

(3) while (CONDITIONjjjh) do //stack not empty or t not explored; 

(4) begin 

{SWJNV A CONDITION^;,} 

(5) if (CONDITIONi)//t is already explored or t is nil; 

(6) then 

{SWJNV A CONDITION^h A CONDITIONi} 

(7) if (CONDITION2) then //POP; 

{SWJNV A CONDITION^ft A CONDITIONi A CONDITION2} 

(8) begin q := t; t ~ p; p := p — ^ r; t — >■ r q; end 
{SWJNV} 

(9) else //TRY right neighbor; 

{SWJNV A CONDITION^h A CONDITIONi A ^C0NDITI0N2} 

(10) begin 

(11) q:=t; t — p ^ r; p ^ r := p ^ I; 

(12) p — > I := q; p — >■ chk := true; 

(13) end 
{SWJNV} 

{SWJNV} 

(14) else //t is not explored. PUSH t into the stack; 

{SWJNV A CONDITION^h A ^CONDITIONi} 

(15) begin 

(16) q:=p; p := t; t := t ^ I; p ^ I := q; 

(17) p — !> mk :— true; p —J- chk := false; 

(18) end 
{SWJNV} 

{SWJNV} 

(19) end 

{SWJNV A ^CONDITION^h} 
^ P ^ AxeNSf, rnk A a; — )► chk A (x- — s> I = Lo(a::) A (x — ^ r = Ro(a;)) 



Fig. 7. The Schorr- Waite Algorithm with Proof 



So we have 9Jt(EXPANDi) n {&q, &t, &p, &p ^ r} = nil, thus 

{SW.INV A CONDITION^,/! A CONDITIONi A CONDITION2} 
=> EXPANDi A (p 7^ nil) 
\ pi-^ EXPANDi 
Outlying(pi,{&q,&t,&p, &p r}) A (p 7^ nil) 

begin q := t; t := p; p ;= p ^ r: t — > r := q; end 
pi A (q = Y) A (t = V) A (p = ^^r) A (t ^ r = Y) 

I pi EXPANDi 
EXPANDi A (t ^) A (p = ^~=Tr) A (t ^ r = Y) 
{SW.INV} 

The assignments in line (10-13). Let EXPAND2 be the formula 

Outlying(po, MSet) A Acyclic(Stack(^ r))A 
OutPath(NS o - p - rng(Stack(p I))) A lnPath(p l)A 
(NextNode(p I) = p) A (Y = Lo(p)) A (i) ^ r = Ro(p)) 

We have 



EXPAND2 ^ (^(EXPANDa) n MSet) C 

{Block(a;)|x 6 NSq - {p}} U {&p mk,&p} 
^ ^(EXPANDa) n {&q, &t, &p^l, &p^r, &p ^chk} = 

Thus we have the following proof, 



{SW.INV A (CONDITION^,,) A (CONDITIONi) A ^(CONDITIONs)} 
=> {EXPAND 2A(p7^ni l)} 

t P2-^ EXPAND2 

{Dutlying(p2, {&q, &t, &p ^ I, &p ^ r, &p chk}) A (p 7^ nil)} 

(10) begin 

(11) q:=t; t := p ^ r: p ^ r := p ^ I; 

(12) p ^ I := q; p chk := true; 

(13) end 

{P2 A (q = Y) A (t = ^^r) A (p ^ r = p^)} A (p ^ I = t)A 
(p — !> chk = true)} 
tp2->EXPAND2 

{EXPAND2 A (q = Y) A (t = ^^r) A (p ^ r = p^l)} A (p ^ I = t)A 
(p chk = true)} 
=> {SW.INV} 

The assignments in line (11) Let EXPAND3 be the formula 

Outlying(po, MSet) A OutP ath(NSo - Y - mg(Stack(^))) A lnPath(V)A 
(NextNode(V) = V) A t~^\ = Lo(V) A t^r = Ro{t) 



Because 



EXPAND3 ^ (»l(EXPAND3) n MSet) C 

{Block(a;)|a; G NSq - 1} U (p ml?0 : {p mk}) 
ajt(EXPAND3) n {&q, &p} U Block(&t) = 

Thus 

{SW.INV A (CONDITI ON^,0 A ^(CONDITIONi)} 
{(t7^nil) AEXPAND 3} 

t P3-^ EXPAND3 
Outlying(/93, {&q, &p} U Block(&t)) A (t 7^ nil) 

(15) begin 

(16) q:=p; p := t; t := t ^ I; p ^ I := q; 

(17) p mk := true; p chk :— false; 

(18) end 

{P3 A (q = V) A (p = Y) A (t = t^l) A (p ^ I = V)A 
(p — ?• mk = true) A (p ^ chk = false)} 
ip3 EXPAND3 

{(q = V) A (p = V) A (t = t -> I) A (p ^ I = ^) A (p ^ mk = true)A 

(p ^ chk = false) A EXPAND3} 
{SW.INV} 

B Yet another example: selection-sort program with 
indirectly specified code 

In this section, we verify an implementation of the selection-sort algorithm. This 
example shows that Scope Logic can verify a template, which is a program with 
a implicitly specified expression. 

B.l the program 

Variables This program has five variables: four variables tmp, i, j, and k with 
type int. and the variable a with type ARR(int, 100). 

The boolean expression order appeared in this program is an implicitly spec- 
ified expression containing two free variables xi and X2- This expression satisfies 
the following conditions 

1. Vx,?/ ■ order[x/xi][y/x2] V order[y / xi][y / X2]; 

2. \fx,y,z ■ order[x/ Xi][y / X2] A order[y / xi][z / X2] => order[x / Xi][z / X2]', 

3. Vx,2/ • order[x / xi][y / X2] A order[y / xi][x / X2] =^ x = y; 

4. M{order) DMSet = 0, where MSet is j&tmp, &i, &j, &k} U Block(&a). 

5. FV{M{order)) ^ 

The expression specifies a total order. Further more, the memory scope term of 
order contains no free variables, and is disjoint with the memory units that may 
be modified by this program. 



Variables: 

i,j, k, tmp declared with type int. 
a declared with type ARR(int, 100) 

(1) i:=0; 

(2) while (i < 100) do 

(3) begin 

(4) j-i + 1; k:=i; 

(5) while (j < 100) do 

(6) begin 

(7) if order (a [j], a [k]) then k ~j; else skip; 

(8) j-j + 1; 

(9) end 

(10) tmp — a[i]; a[i] := a[k]; a[k] — tmp; i — i + 1; 

(11) end 



Fig. 8. The Selection-Sort Algorithm 



B.2 The Recursive Functions and Their Memory Scope Functions 

The recursive functions used in this proof are depicted in FigurelHl OrderSet(a;, y) 
means that x is less than or equal to all the elements in y w.r.t. order. The func- 
tion OrderSetSet(si, S2) means that all elements in si is less than all elements in 
S2 w.r.t. order. The function DataSet(Z,r) represents the set of elements indexed 
from / to r in a. AIIBut(Z, r, i, 7) represents the set of elements indexed from I to 
r in the array a except that a[i] and a [7] are excluded. The function arrLocs(/, r) 
computes the set memory units used by the array elements index from ^ to r. 
The corresponding simplified memory scope functions (or over-approximation) 
are depicted in Figure [TUl 

OrderSet(a:: : int, s : SetOf(int)) : bool = Aygs order{x,y) 

OrderSetSet(si : SetOf(int), S2 : SetOf(int)) : bool = Ayg^^ OrderSet(y, S2) 

Sorted(/ : int,r : int) : bool 

= (r < 0?true : order{a[l], a[l + 1]) A Sorted(Z + 1, r) 
DataSet(Z : int, r : int) : SetOf(int) 

= (r < O?0 : {a[l]} U DataSet(Z + 1, r) 
AIIBut(i : int,r : int,i : int,j : int) : SetOf(int) 

= (r < O?0 : {{l = iWl= j)?0 : {a[i\}) U AIIData(Z + 1, r) 
arrLocs(/ : int,r : int) : SetOf(Ptr) 

= (r < O?0 : U arrLocs(/ + 1, r) 



Fig. 9. The recursive functions used to prove the selection-sort algorithm 



Recursive functions 


Memory Scope functions (or over-aproximation) 


OrderSet, OrderSetSet 




arrLocs 





Sorted(/, r), DataSet(/, r) 


arrLocs(/, r) 


A\\But{l,r,i,j) 


arrLocs(i,r) — {&a[i], &a[7]} 



Fig. 10. The memory scope functions or over-approximations 



Fig. 11. The properties used in the proof 



B.3 The Specification 

This is an implementation of the selection-sort algorithm. This algorithm sort 
the integers in the array. It modifies only the memory units in MSet. So the 
specification is as follow. 

Outlying(po,M5'et) A 5o = DataSet(0, 99) 

{The program} 
Dutlying(/9o, MS'et) A 5o = DataSet(0, 99) A Sorted(0, 99) 

B.4 The Proof in Code 

The invariant of the outer while-statement, denoted as INVo, is as follow. 
Dutlying(/9o, MS'et) A (i < 100) A 

Sorted(0, i - 1) A OrderSetSet(DataSet(0, i - 1), DataSet(i, 99))A 
5*0 = DataSet(0,99) 

S[n(INVo) is 

M{po) U {&i} U m{order) U arrLocs(0, 99) 
The invariant of the inner while-statement, denoted as INV^, is as follow. 

Outlying(p,,{&k,&j})A 

OrderSet(a[k], DataSet(i, j - 1)) A (0 < i < k < 100) A (0 < j < 100) 
Let EXP be the formula 

Outlying(po, MSet) A Sorted(0, Y - 1)A 

OrderSetSet(DataSet(0, Y - 1), AIIBut(Y, 99, Y, k) U {a|i], a|l<]})A 
OrderSet(a[k], AIIBut(Y, 99, Y, k)) A order(a[k], a[i]) A order{t\k],t\k]) 



OJt(EXP) is 

m{po) U {&k} U arrLocs(0, 99) - {&a[k], &a[^]} 

Figure [T^ presents the proof of this program with indirectly specified expres- 
sion. The following is some properties used in this proof. 

<l <i,j <r <99^ DataSet(;,r) = A\\But(l,r,iJ) U {a[i],a[j]} 

order{x, y) A OrderSet(a;, s) OrderSet(a;, s U {y}) 
OrderSetSet(si, S2) A OrderSet(a;, S2) OrderSetSet(si U {x}, S2) 



{Outlying(po, A/Set) A So = DataSet(0, 99)} 

(1) i:=0; 

{Outlying(po, MSet) A So = DataSet(0, 99) A (i = 0)} 
{iNVo} 

(2) while (i < 100) do 

(3) begin 

{iNVo A (i < 100)} 

(4) j — i + 1; k:=i; 

{iNVo A OrderSet(a[k], DataSet(i, j - 1)) A (0 < i < k < 100) A (0 < j < 100)} 

t p, INVo 
{INV,} 

(5) while (j < 100) do 

(6) begin 

{INV, A (j < 100)} 

(7) if order (a [j], a [k]) then k ~ j; else skip; 

{Outlying(pi, {&k,&j}) A order (a [k], a [j]) A (0 < i < k < 100)A 
OrderSet(a[k], DataSet(i,j - 1)) A (j < 100)} 

(8) j - j + 1; 
{INV,} 

(9) end 

{INV, A^(j < 100)} 

{Qutlying(/9,, {&k, &j}) A OrderSet(a[k], DataSet(i, 99))} 
i pi ^ INVo 

{INVo A OrderSet(a[k], DataSet(i, 99)) A (0 < i < k < 100)} 
{(0 < i < k < 100) A EXP} 

{0utlying(p2,{&i,&:tmp,&a[i],&a[k]}) A (0 < i, k < 100)} 



{P2 A (a[i-l] = a[k]) A (a[k] = a[i]) A (i = T + 1)} 
i p2 EXP 

{(a[i-l] = t\k]) A (a[k] = ^) A (i = Y + 1) A EXP} 
{INV„} 
(11) end 

{INVo A ^(i < 100)} 

{Outlying(po, MSet) A So = DataSet(0, 99) A Sorted (0, 99)} 



(10) 




Fig. 12. The Selection-Sort Algorithm with Proof 



